Repository navigation
Conversation
|
@jpagnucco to clear the automated ipr check for this and any future contributions, please check that your W3C account is associated with your GH account. That'll fix it. |
|
Hey! Thanks for getting the draft started on this @jpagnucco, been left for a TODO for a while. I like the content here, but now that I'm reading the whole section together, the title and framing feel a bit off. Titling it "violation" feels wrong when most of what's described is the careful design that prevents cross-document exposure without permission. I would prefer to retitle this section to something like "Cross-origin tool exposure" and reorder what you currently slightly have so it leads with the consideration and ends with the residual risk. Roughly:
|
… end with residual risks
victorhuangwq
left a comment
victorhuangwq
left a comment
There was a problem hiding this comment.
Thanks for the update, this looks good to me! I cross-checked it against the current spec and I didn't spot any inconsistencies.
@domfarolino tagging you for review and merge.
| </p> | ||
| <ul> | ||
| <li> | ||
| <strong>Direct Cross-Origin Exposure</strong>: Even when two [=origins=] mutually opt in via {{ModelContextRegisterToolOptions/exposedTo}} and {{ModelContextGetToolOptions/fromOrigins}}, they remain separate trust domains: tool providers must still treat caller-supplied arguments as untrusted input, and callers must treat cross-origin tool descriptions and return values as untrusted data (see [[#prompt-injection]]). Additionally, because {{ModelContext/getTools()}} aggregates tools across all descendant frames at the [=origin=] level, callers should inspect {{RegisteredTool/origin}} and {{RegisteredTool/window}} on each {{RegisteredTool}} to disambiguate tools when multiple subframes or [=origins=] expose tools with the same {{RegisteredTool/name}}. |
There was a problem hiding this comment.
This is a good callout.
| <h4 id="violation-same-origin-boundaries">Violation of Same-Origin Boundaries</h4> | ||
| <h4 id="interaction-with-same-origin-policy">Interaction with the Same-Origin Policy</h4> | ||
|
|
||
| The Same-Origin Policy (SOP) is the foundational security boundary of the web platform, isolating documents of different [=origins=] so that one [=origin=] cannot inspect or manipulate the state of another without explicit consent. |
There was a problem hiding this comment.
I was going to comment about wrapping lines to be consistent, but then saw what looks like wildly varying styles in the spec, and gave up. 🤷
|
|
||
| The Same-Origin Policy (SOP) is the foundational security boundary of the web platform, isolating documents of different [=origins=] so that one [=origin=] cannot inspect or manipulate the state of another without explicit consent. | ||
|
|
||
| In WebMCP, a registered tool's {{ModelContextTool/execute}} callback always runs within the registering {{Document}}'s execution context, with full access to that [=origin=]'s DOM, storage, and ambient credentials. Consequently, allowing a cross-origin {{Document}} in the frame tree to discover a tool ({{ModelContext/getTools()}}), invoke it ({{ModelContext/executeTool()}}), and receive its serialized return value crosses a privilege boundary. Without strict enforcement, a malicious embedding page or embedded subframe could silently invoke privileged operations or extract sensitive state from another [=origin=]. |
There was a problem hiding this comment.
A malicious main frame could to this to a benign embedded frame as well?
a malicious frame (either a main frame or an embedded frame) could silently...
| <strong>Direct Cross-Origin Exposure</strong>: Even when two [=origins=] mutually opt in via {{ModelContextRegisterToolOptions/exposedTo}} and {{ModelContextGetToolOptions/fromOrigins}}, they remain separate trust domains: tool providers must still treat caller-supplied arguments as untrusted input, and callers must treat cross-origin tool descriptions and return values as untrusted data (see [[#prompt-injection]]). Additionally, because {{ModelContext/getTools()}} aggregates tools across all descendant frames at the [=origin=] level, callers should inspect {{RegisteredTool/origin}} and {{RegisteredTool/window}} on each {{RegisteredTool}} to disambiguate tools when multiple subframes or [=origins=] expose tools with the same {{RegisteredTool/name}}. | ||
| </li> | ||
| <li> | ||
| <strong>Agent-Mediated Cross-Origin State Transfer</strong>: Where an external or browser-integrated [=agent=] ([=browser's agent=]) interacts with multiple [=origins=] over the course of a task and carries state derived from one [=origin=] into tool invocations on another [=origin=]. This is a general risk of agentic browsing across the web rather than a WebMCP-specific threat. |
There was a problem hiding this comment.
This could call out specifically the risk of carrying private data across origins through tool calls, and the ability for the output of a tool from one origin influencing the actions of the agent on another origin.
This branch has not been deployed
4 participants
Summary
Replaces the
TODOplaceholder in Section 6.3.4 (Violation of Same-Origin Boundaries) (#violation-same-origin-boundaries) with documentation covering:getTools()andexecuteTool().allow="tools"): Gated behind the"tools"policy-controlled feature ('self'default allowlist).exposedTo): Explicit allowlisting of potentially trustworthy origins inModelContextRegisterToolOptions.exposedTo.fromOrigins): Explicit opt-in by the caller viaModelContextGetToolOptions.fromOrigins.Preview | Diff